Resolves #7296(FR-2840)

## Summary

Upgrade the repo from pnpm v10 to pnpm v11 in a single PR. Predecessor PR #7297 (FR-2839) temporarily pinned CI workflows to pnpm v10 to unblock CI; this PR completes the migration so we don't get stuck on v10.

## Key decisions and rationale

The migration ran into several pnpm 11 behavior changes and upstream bugs that required explicit decisions. These were discussed and chosen during implementation; this section is the lasting record so the decisions don't have to be re-derived in review.

### 1. Single PR for the whole migration

**Decision**: deliver as one PR (config moves + workflow updates + lockfile regen).

**Rationale**: lockfile regen, config moves (`pnpm.overrides` → `pnpm-workspace.yaml`), `onlyBuiltDependencies` → `allowBuilds` conversion, and the workflow `version: 11` bump must land **atomically** — splitting forces an intermediate commit where either CI is on v10 with v11 config (breaks) or on v11 with v10 config (breaks). The dev plan documents this reasoning at `.specs/FR-2840-pnpm-v11-migration/dev-plan.md`.

### 2. Drop `package.json` `pnpm` field; absorb `overrides` into `pnpm-workspace.yaml`

**Decision**: move the three `overrides` (`tar-fs@2`, `node-forge`, `@codemirror/state`) into `pnpm-workspace.yaml` and delete the top-level `pnpm` block from `package.json`.

**Rationale**: pnpm 11 no longer reads the `pnpm` field in `package.json`. Leaving it would silently lose those overrides at install time.

### 3. `onlyBuiltDependencies` (list) → `allowBuilds` (map)

**Decision**: 1:1 conversion — same 9 packages (`bufferutil`, `core-js`, `core-js-pure`, `electron`, `es5-ext`, `esbuild`, `sharp`, `unrs-resolver`, `utf-8-validate`).

**Rationale**: `onlyBuiltDependencies` was removed in pnpm 11; `allowBuilds` is its replacement.

### 4. Drop `minimumReleaseAgeExclude` block entirely

**Decision**: remove the seven entries (`react@19.2.4`, `i18next@25.7.4`, `antd@6.1.3`, …).

**Rationale**: those entries pinned exact versions that the catalog has long since moved past. Under pnpm 11 the entries no longer match anything in the resolved tree, so they're dead config.

### 5. Drop `engine-strict=true` from `.npmrc`

**Decision**: remove the line; replace `.npmrc` with a one-line comment about scope.

**Rationale**: pnpm 11 enforces `engines.pnpm` natively when set, and v11 narrows `.npmrc` to auth/registry settings only.

### 6. Bump `pnpm/action-setup` references to `@v5` everywhere (also fixes `vitest.yml@v4`)

**Decision**: every `pnpm/action-setup` reference uses `@v5` or the matching v5 SHA; `.github/aw/actions-lock.json` is updated to the v5 SHA (`a8198c4bff370c8506180b035930dea56dbd5288`).

**Rationale**: `vitest.yml:146` was on `@v4` while siblings were `@v5` — flagged as cleanup during PR #7297 review. While in the area, also bumped agentic `e2e-watchdog.md`/`e2e-healer.md` and the SHA-pinned `.lock.yml` siblings so the next gh-aw regen doesn't re-introduce v4.

### 7. CI: every install lane uses `--frozen-lockfile`; `--config.minimum-release-age=0` only on the weekly-merge job

**Decision**: see the table below. Every CI `pnpm install` runs `--frozen-lockfile`. The single intrinsic exception is `weekly-merge-branch-lockfiles.yml`, whose purpose **is** to re-resolve and merge per-branch lockfiles.

| Workflow | Mode | Override needed? |
|---|---|---|
| `vitest.yml` (3 jobs) | `--frozen-lockfile` (was `--merge-git-branch-lockfiles --no-frozen-lockfile`) | ❌ No |
| `package.yml` (5 lines) | `--frozen-lockfile` (was `--no-frozen-lockfile`) | ❌ No |
| `daily-test-improver/coverage-steps/action.yml` | `--frozen-lockfile` (was `--no-frozen-lockfile`) | ❌ No |
| `publish-backend.ai-{ui,docs-toolkit}.yml` | `--frozen-lockfile` | ❌ No |
| `e2e-{watchdog,healer}.{md,lock.yml}` | `--frozen-lockfile --prefer-offline` | ❌ No |
| `weekly-merge-branch-lockfiles.yml` | `--merge-git-branch-lockfiles --no-frozen-lockfile --config.minimum-release-age=0` | ✅ Yes (intrinsic) |

**Rationale**: pnpm 11's stricter `minimumReleaseAge` enforcement breaks `pnpm install` against this dep tree in two ways the upstream does not yet fix:

1. **`ERR_PNPM_MISSING_TIME` (cache/metadata bug)** — pnpm 11 fatals on packages whose npm registry abbreviated metadata is missing the `time` field, even though the full metadata file has it. Tracked in [pnpm/pnpm#9963](pnpm/pnpm#9963) (closed but recurring) and [pnpm/pnpm#9968](pnpm/pnpm#9968) (10.16.1 fix is partial). Maintainer comment on #9963: *"the error should not happen at all. The full metadata and the abbreviated one are stored at different locations."* The recommended `pnpm store prune` workaround did not produce stable results — re-tested after each iteration and the error reappeared on different packages.
2. **Optional/platform binaries fataling** — `vitest`/`rollup`'s `optionalDependencies` declares 15+ `@rollup/rollup-*` platform binaries. Pnpm 11 fatals on each one's missing `time` metadata. Same shape as [pnpm/pnpm#10699 (open)](pnpm/pnpm#10699).

These bugs only fire during **resolution**. Once the lockfile is generated, `--frozen-lockfile` installs from it without re-resolving and never touches the time check — so 99% of CI lanes don't need any workaround at all. Only `weekly-merge-branch-lockfiles.yml` has to re-resolve (its purpose is to merge per-branch lockfiles into the canonical), so it's the only place that carries the override.

This decision was the result of three rounds of refinement: started with override on every install, narrowed to "only re-resolve lanes" after empirical scoping, then narrowed again to "only the one re-resolve lane that exists" by switching the rest to `--frozen-lockfile`. The earlier exclude-list approach (add offending packages to `minimumReleaseAgeExclude`) was attempted and abandoned — empirical iteration grew the list past 30 entries without converging because every new rollup architecture binary, every metadata corruption, and every recent typescript-eslint family bump re-broke it.

### 8. Trade-off accepted with `--frozen-lockfile`

**Decision**: PRs that change deps must run `pnpm install` locally and commit the updated lockfile (or branch lockfile) before pushing. CI no longer auto-resolves on those PRs.

**Rationale**: stricter contract, but more honest. CI's role is to verify, not to silently mutate the lockfile. Local devs that hit MISSING_TIME / NO_MATURE during their manual install can use `pnpm install --config.minimum-release-age=0` as a one-off until upstream pnpm fixes #9963 / #10699.

### 9. Keep `minimumReleaseAge: 10080` in `pnpm-workspace.yaml`

**Decision**: don't lower the policy value to 0 or 1440 just because pnpm 11 makes it painful.

**Rationale**: the 7-day supply-chain protection is a deliberate project policy. The pnpm 11 enforcement bugs are temporary upstream issues; the policy outlives them. Workflow-level override scopes the relaxation to the one place that genuinely needs it (the merge job, which a human reviews before merging the resulting PR).

### 10. Out of scope (deliberate)

- Per-branch `pnpm-lock.<branch>.yaml` files for other developers' branches are intentionally **not** consolidated in this PR. The `weekly-merge-branch-lockfiles` workflow already handles that on its own cadence.
- Pre-existing TypeScript errors (`packages/backend.ai-client/src/client.ts` implicit-`any`s, `DeleteForeverVFolderModalV2.tsx` `BulkPurgeVFoldersV2Input.options`) — verified to exist on `main`, not introduced by this migration.
- Re-evaluating the long-term `minimumReleaseAge` policy. Spec §5.4.1 documents the single CI exception; a strategic decision can come in a follow-up once pnpm fixes the upstream bugs.

## Test plan

- [x] `pnpm install --frozen-lockfile` succeeds locally under pnpm 11.0.8 against the regenerated lockfile (~10s, no MISSING_TIME / NO_MATURE errors).
- [x] `bash scripts/verify.sh` — Relay/Lint/Format pass; TypeScript failures are confirmed pre-existing on `main` (verified by checking out `main` and re-running). Out of scope for this PR.
- [ ] CI on this PR — `Analyze`/`CodeQL`/`triage`/`mergeability_check`/`auto-label`/`sync-project-status` pass.
- [ ] After merge, re-run failed CI on a recent PR (e.g. on top of this) and confirm `pnpm -v` reports 11.x and the install step passes.

## Spec

Full migration spec is committed in this PR at `.specs/FR-2840-pnpm-v11-migration/spec.md` with the §8 acceptance checklist for the reviewer to tick.